The present invention relates generally to management of information or datasets stored on electronic devices and, more particularly, to a system implementing methods for maintaining synchronization of disparate datasets among a variety of such devices.
With each passing day, there is ever increasing interest in providing synchronization solutions for connected information appliances. Here, the general environment includes “appliances” in the form of electronic devices such as cellular phones, pagers, hand-held devices (e.g., Palm Pilot™ and Windows™ CE devices), as well as desktop computers and the emerging “NC” device (i.e., a “network computer” running, for example, a Java virtual machine or a browser).
A problem facing such an environment today is that these devices do not communicate well with desktop computers, let alone with each other. In particular, a problem exists as to how one integrates disparate information—such as calendaring, scheduling, and contact information—among disparate devices. Consider, for instance, a user who has his or her appointments on a desktop PC but also has a battery-powered, hand-held device for use in the field. What the user really wants is for the information of each device to remain synchronized with all other devices in a convenient, transparent manner. Still further, the desktop PC is typically connected to a server computer, which stores information for the user. The user would of course like the information on the server computer to participate in the synchronization, so that the server also remains synchronized.
There have been various attempts to solve this problem. An earlier approach to maintaining consistency between datasets was to import or copy one dataset on top of another. This simple approach, one which overwrites a target dataset without any attempt at reconciling any differences, is inadequate for all but the simplest of applications. Expectedly, more sophisticated “synchronization” techniques were developed.
Perhaps the most common synchronization approach is one employing a “star” topology—that is, a topology where each one of the dataset writes to a common universal dataset which encompasses all of the other datasets. FIG. 1 summarizes the basic approach. In a star topology, when writing to the universal dataset or “unirecord,” the only device-dependent functionality that needs to be written is that for converting information to and from the unirecord. By employing the abstraction of a unirecord, support for a new platform is typically easier to implement.
This approach of supporting the least common denominator has its disadvantages, however. Consider the task of storing menu information for every restaurant in the San Francisco Bay Area using a gigantic “universal” menu that covers every restaurant. The advantage to this approach is that one need only to develop or implement a mechanism that writes to this universal schema. The disadvantage to this, however, is that the approach can compromise the dataset. Here, if a particular item of a record cannot be represented or mapped to the universal schema, information might be lost. For instance, “rich data” (e.g., formatted or “rich” text) on one particular device mapped down to a universal representation employing simple (ASCII) text will result in loss of some content.
Another attempt is to employ synchronization using a “mesh” topology, which is illustrated in FIG. 2. Instead of using a common universal schema, the approach is to implement device-dependent drivers for mapping a dataset from one device to another, basically making sure that data is appropriately mapped between any two devices. For instance, if a user wishes to synchronize a dataset residing on a desktop PC using Starfish Sidekick® PIM (Personal Information Manager) with a dataset residing on a Palm Pilot™, the system designer must provide a specific driver supporting the Sidekick-to-Palm Pilot transfer. If a Palm Pilot™ device needs to “talk” with (i.e., reconcile its dataset with) another third party PIM, yet another driver must be provided. Thus, for n possible conduits (i.e., one-way connection between two devices), the system vendor must supply n number of drivers—one for each conduit that needs to be supported. The advantage of the approach is that any two devices can communicate natively, without relying on a universal abstraction. Since there are two conduits for every device which must communicate bidirectionally, however, the approach quickly becomes burdensome if any significant number of conduits need to be supported.
What is needed is a solution which handles all the different types of data from a variety of different devices, that is, providing support for different datasets. At the same time, the approach should be automated so that the user is provided with “one-click” convenience. The present invention fulfills this and other needs.